fix(app-shell): forward the authored chart block WHOLE to ListView, not a six-key projection (objectui#7823) - #7890

Fixes #7823

ObjectView's renderListView relay handed ListView a hand-listed projection of
exactly six keys of the authored chart: block. This replaces that copy with a pointer.

What was measured, before any code was touched

The card was written at 900f8d995 and flagged three things as unverified or
carried-over. All three were re-read line by line on origin/main 83fe6e741.

1. The line numbers still hold. The dedicated chart-view branch is still at :2098,
the fullSchema literal still opens at :2170, and the six-key chart: projection was
still at :2435.

2. InterfaceListPage does NOT carry the same projection — and the card's "maybe it
does not relay it at all" is the closer half of its guess. It never names chart, and
it hand-lists nothing: it forwards the referenced view's options bag WHOLE
(options: { ...(view.options ?? {}), ...(mapCfg ? { map: mapCfg } : {}) }, :477), so
a chart block authored under options passes through untouched. It relays no
view-level chart: key at all — but it does relay the view-level map block verbatim
one line above (...((view as any).map ? { map: (view as any).map } : {})), which is the
in-repo precedent for the shape this PR writes. The six-key projection is unique to
ObjectView.tsx, so this fix is correctly scoped to one file and no second host needs
the same edit.

3. The spread order — and a CORRECTION to the card. The card asserts that
schema.chart at the ListView end "is the object-level list's block, never the active
view's". The first half of that is right as a mechanism and wrong as a reading:

• fullSchema does spread ...listSchema first (:2171) and declares no top-level
  chart: rung, so nothing overrides whatever the spread carries.
• But the listSchema this relay receives is built by plugin-view's ObjectView
  (:1747), and that literal has no chart key at all. So schema.chart at the
  ListView end is undefined on this route — not an object-level chart block. There is
  no object-level block to shadow the view's, because none is ever constructed.
• The six-key projection is nested inside options: (:2371), not at the top level of
  fullSchema, so what the gate actually consulted was schema.options.chart.

Net effect on the gate, which resolves schema.chart || schema.options?.chart || {}:
undefined || sixKeyHusk — the husk won every time, because an object of six
undefined values is truthy. The card's conclusion (the ADR-0021 shape never arrives)
is correct; its route is not, and only the projection needed fixing.

The fix: a pointer, not a wider copy

chart: viewDef.chart,

Widening the list from six keys to nine would buy ADR-0021's correctness and re-arm the
identical trap for the next block key, with nothing to fire when it happens: viewDef is
an untyped record (Record of string to any), so a missing rung is invisible to tsc (#7559 owns that mechanism
and explicitly disclaims this census). A hand-listed key set is a copy of a schema's key
set, and copies rot silently.

The whole relay carries no key ListView can trip over, and this was checked rather
than assumed (the ruling's stop-and-report condition). ListView never SPREADS this
block: resolveListChartBinding and case 'chart' both read it BY NAME — dataset,
dimensions, values, chartType, xAxisField, yAxisFields, categoryField,
valueField, aggregation, series. Keys it does not consult are ignored exactly as
they already are for the gantt / timeline / tree blocks in the same literal, which
are relayed whole today. No stop-and-report condition was met.

One shape change worth naming: an undeclared block now forwards undefined instead of a
permanently-truthy husk of six undefined keys. Both resolve to "no binding" at the gate,
so the observable answer is unchanged — and the negative controls below pin that.

Behaviour evidence — a reading BEFORE and AFTER

New test packages/app-shell/src/views/ObjectView.chartRelay-7823.test.tsx mounts the
real ListView behind the real relay (the sibling relay tests stub it; this card's claim
is about the capability gate one seam further on, so the assertion is the Chart toggle in
the DOM, per the #6318 standard that it renders differently).

The gate under test is the live one, not a stale build: the root vitest config aliases
@object-ui/plugin-list to packages/plugin-list/src, so the ListView that rendered
here is current source carrying #7544's capability check.

Measured run counts: before 5 failed / 3 passed; after 8 passed. Four of the five
failures are the THE FIX arms; the fifth is the SCHEMA half of the first negative
control (options.chart was the husk, not absent) — its DOM half, the toggle, was green
before and stayed green after. Every negative control's behaviour assertion is green in
both worlds, which is what refuses a "fix" that merely widens the husk and lights the
toggle on views that configured no chart.

What this is not

Not #7559 (that card owns the mechanism and disclaims the census; this is a rung that
EXISTS and narrows, which a rung census cannot report because the key is present). Not
#7547 / #7029 / #7070 — those are invented binding names on the FORCED path; nothing here
adds or removes a floor. Not #7544 itself, which is packages/plugin-list and lands the
gate this relay now feeds. packages/plugin-list/ and packages/types/ are untouched.

Gates, re-run on the pushed commit 4fed69acc with git diff HEAD empty

• node scripts/check-changeset-presence.mjs — EXIT=0, verbatim: 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s): .changeset/7823-objectview-chart-relay-whole-block.md. Scored patch.
• node scripts/check-changeset-no-major.mjs — EXIT=0, No changeset declares a major bump.
• node scripts/check-governed-queue-guard.mjs --test over the three changed paths —
  EXIT=0, verbatim: NOT GOVERNED - 3 path(s) checked against 5 governed surface(s); none matched. An ordinary pull request: the normal review and merge-queue route applies.
• pnpm check:control-bytes, check:vi-mock-specifiers, check:vi-mock-inherit,
  check:governed-queue-guard — all EXIT=0.
• pnpm --filter @object-ui/app-shell type-check — EXIT=0. The new test file's presence
  in that program was confirmed with --listFiles (1 hit) rather than assumed, since the
  emitting tsconfig excludes test directories.
• pnpm exec vitest run packages/app-shell/src/views/ (the changed file's whole
  directory, recursive) — EXIT=0, Test Files 376 passed (376),
  Tests 3580 passed | 1 skipped (3581). No sibling relay or view test regressed.
• pnpm --filter @object-ui/app-shell lint — EXIT=0, 0 errors.
• node scripts/check-lint-coverage.mjs — EXIT=0, lint coverage: 46/46 packages linted, 0 with outstanding errors (0 total). (Its first run through pnpm -s exited 254 with
  EMPTY output while the test suite held memory — read as "could not run", not as a
  finding, and re-measured directly.)
• pnpm check:unreferenced-sources, check:handler-key-reads, check:i18n-keys — all
  EXIT=0.

Exit codes were captured by redirecting first, never through a pipe.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3

Generated by Claude Code